-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add support for multiple schedulers #1781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of joining on the scheduler threads, instead keep a count of active schedulers. When there are no more schedulers raise a signal for the main thread to continue. This will be required once schedulers can be added and removed from the running kernel.
This will be needed once we support dynamically changing schedulers.
This is in preparation for giving schedulers their own life cycle separate from the kernel. Tasks must be deleted before their scheduler thread, so we can't let the scheduler exit before all its tasks have been cleaned up. In this scheme, the scheduler will unregister tasks with the kernel when they are reaped, then drop their ref on the task (there may still be others). When the task ref count hits zero, the task will request to be unregistered from the scheduler, which is responsible for deleting the task. Instead of having the kernel tell the scheduler to exit, let the scheduler decide when to exit. For now it will exit when all of its tasks are unregistered.
This function creates a new scheduler with a specified number of threads and immediately executes a task on it. The scheduler is configured to terminate when the task dies. This is the minimum API necessary to enable blocking C calls.
Thanks! Merged. |
xFrednet
pushed a commit
to xFrednet/rust
that referenced
this pull request
May 21, 2022
New lint: [`derive_partial_eq_without_eq`] Introduces a new lint, [`derive_partial_eq_without_eq`]. See: rust-lang#1781 (doesn't close it though). changelog: add lint [`derive_partial_eq_without_eq`]
Kobzol
pushed a commit
to Kobzol/rust
that referenced
this pull request
Dec 30, 2024
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This series adds support to the kernel for dynamically adding and removing schedulers then adds a single user-visible function,
task::spawn_sched
for spawning a task into a new scheduler. I have not implemented the full design for first-class schedulers, and think I may let this sit as-is for awhile while we review what we want thecore::task
API to look like (it's quite a mess these days).For the most part this is not that interesting, but commits bde9385, 0f4ca21, and 36d5181 make big changes to the scheduler and task lifecycle and synchronization protocols to eliminate races between scheduler and task destruction and allow schedulers to be destroyed while the kernel is running. It's a little mind-bending, with a lot of events happening on various threads, and I probably can't explain how the kernel/scheduler/task_thread/tasks cooperate to shutdown the kernel without tracing through the code, but I left lots of comments.
This change also breaks
rust_kernel::fail
(the function that kills all tasks) even worse than before. It's very racy, but doesn't break any existing tests.I'm doing some stress tests now to make sure things are still reliable.